home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Merciful 4
/
Merciful - Disc 4.iso
/
developers
/
screens
/
screens.doc
next >
Wrap
Text File
|
1996-11-01
|
7KB
|
120 lines
Notes on the Screens Used by Cloanto Graphics Software
November 2, 1996 - All Versions
For more information please send E-mail to <support@cloanto.com>,
or check <http://www.cloanto.com/amiga/>.
Introduction
Except where indicated otherwise, these notes apply to the screens opened
by Personal Paint, Personal Fonts Maker 2 and ColorType screens. The
information contained herein has been written for developers of software
which locates, grabs, selects, switches to front/back, promotes or performs
other functions on screens.
Screen Title Information
The Cloanto packages to which these notes apply do not have a Screen title
(the corresponding pointer is NULL). This was not possible, as under many
conditions it could not be afforded to have a standard screen bar with
system-rendered text indicating the name of the program and potentially
overwriting other data. A consequence of this is that software that scans
the list of Amiga screens needs to take additional steps if it wants to
locate information such as the screen title, rather than presenting an
empty field to the user.
All Cloanto graphics programs can easily be recognized. If the scan of the
list of windows in a screen having a NULL title determines that it contains
a window as wide as the screen, and one pixel tall, then it is very likely
a Cloanto screen of the type described here. The UserData field of that
window points to the title. To make the process reliable even in the event
that another application uses a similar format, it is best to check that
UserData is non-NULL, and that the string ending with '\0' has a
"reasonable" length (<255) and does not contain any unprintable characters
(having codes smaller than 32, or ranging between 127 and 159).
Screen Promotion
While Cloanto packages are in general compatible with screen "promoters"
(utilities that intercept a request to open a given screen, and open
another type and/or size of screen instead), it is never safe to promote
from double-buffering to non-double-buffering modes (in the case of
Personal Paint playing an animation), or from non-RTG to RTG modes, or vice
versa. In case of difficulties, the documentation of Personal Paint advises
the user to disable the screen promoting software. Ideally, any screen
promotion software should include similar notices, or make similar
considerations.
Transition Screen
When Cloanto programs change screen mode (for example, from PAL to NTSC),
they try to prevent that the System Workbench screen opens (if it was
closed) or appears to the front. This would be possible by opening the new
screen first, and then closing the old screen, but doing so has the
disadvantage of requiring, for a brief moment, possibly almost twice as
much RAM, which may not be available. Therefore, Cloanto programs such as
Personal Paint first open a one-bitplane transition screen, then close the
first screen, open the new screen and finally close the transition screen.
The transition screen also contains a window, in order to always satisfy
Console I/O requirements in case there is no other window in the system.
During the transition phase, both the transition screen and the mouse
pointer sprite are colored with the current color 0, to make them as
"discrete" as possible. The size of the transition screen is as small as is
allowed by the Display Database information, and in any case not smaller
than 320×200 (it used to be smaller in older versions of Personal Paint,
but some graphic systems which contained incorrect Display Database entries
would crash). The reason why the screen has only one bitplane and is as
small as possible is that it must occupy as little RAM as possible.
We encourage developers of Amiga compatible graphics subsystems to test
their system with Personal Paint changing screen modes between various
Amiga modes and various other screen modes. We have learned that the quick
and repeated actions of opening and closing various screens and windows is
a good way to test such a graphic system.
Virtual Blitter
Cloanto packages always used the Amiga (Agnus) blitter according to the
official Amiga system specifications, in an OwnBlitter()/DisownBlitter()
context. In the case of RTG environments which use Fast RAM for bitmaps, a
copy of the bitmap was created in Chip RAM, if this was required to give
the Amiga blitter access to the data.
In more recent times, the use of the blitter, once an advantage the use of
which was encouraged by Commodore, has more and more become a penalty: not
only are recent CPUs faster than the Amiga blitter, but certain systems
(e.g. DraCo) do not provide low-level blitter functionality. Also, RAM
requirements now tend to abundantly exceed the limited sizes of the Chip
RAM which can be accessed by the original Amiga blitter.
Personal Paint 7 includes a set of "virtual blitter" functions, which use
the CPU or other processors to achieve effects previously delegated
exclusively to the Amiga blitter (and which therefore required Chip RAM).
The program can selectively or automatically use a library employing the
Amiga blitter, or rather use another library which uses the CPU. This is of
advantage when there is no blitter, when the CPU is faster than the
blitter, and/or when Chip RAM is particularly slow or precious (as long as
graphics.library functions do not require Chip RAM, which is also checked
for). Hybrid libraries are also possible, as are 68K-replacement libraries
(e.g. PowerPC), or 68K libraries especially compiled for certain processors
(e.g. 68040).
The user can normally switch between the use of one library and the other
by toggling the "Blitter" setting in the program user interface. In the
event that the "Blitter" setting is active, but there is no blitter, the
program tries to detect this condition and use the other library. Detecting
this condition (no blitter on the host system) is not standard (not having
a blitter is "not standard"...), especially when Amiga blitter
functionality is partially emulated, and we therefore would ask developers
of new "blitterless" systems to let us know how such a condition can be
detected, so that we can update the libraries. Also, we would very much
like to know about any new graphic systems in which the graphics.library
functions can work on Fast RAM (e.g. how that can be detected, what
functionality is provided).